你將學到

• Odoo 18 中整合 AI 功能的介面設計原則
• 提示詞輸入區與 AI 回饋區塊的設計方法
• UI 回饋技巧、提升 UX 策略

關鍵字

UX Pattern、OWL、QWeb

AI 友善介面設計原則

在為 AI 功能設計介面時，核心原則是融入上下文、保持可控。

Odoo 18 已將許多工具直接嵌入現有介面（如表單檢視、側邊欄、編輯器等）。也就是說，AI 功能出現在使用者操作的畫面上，而不是跳出另一個干擾性的窗口。這種做法讓使用者無需切換環境，就能即時獲得 AI 協助。

例如，一鍵重寫或語氣調整的建議按鈕直接出現在郵件編輯器中，使用者不需離開 Odoo 介面即可取得量身打造的郵件建議。

為了讓 AI 真正成為使用者的幫手而非負擔，我們需確保使用者始終保有最終控制權。

介面應提供 AI 建議作為選項而非強制變更：模型生成的內容通常以草稿或建議形式呈現，等待使用者確認或編輯後再正式採用。這意味著 AI 的輸出必須可被使用者調整——例如，自動產生的回覆可以先顯示在輸入框中，讓支援人員修改措辭後再送出，而不是直接由機器替他們回覆。體現 AI 提供初稿、人類掌握決定的原則。

另一項重要原則是提示輸入區域緊鄰相關資訊脈絡。也就是說，如果需要使用者輸入提示詞（prompt）來引導 AI，這個輸入框應該放在使用者正查看的資訊附近。

比方說，在客服工單 (Helpdesk Ticket) 詳情頁面上，可以在對話紀錄旁放置「AI 助手」按鈕或輸入框，以便根據當前對話內容來產生回覆建議；在 CRM 商機頁面中，則可在聯絡記錄區域附近提供「AI 摘要」按鈕，以利用現有客戶資訊進行分析建議。上下文相關的介面佈局讓使用者感知 AI 功能和目前任務是緊密相連的。

最後，清晰標識 AI 內容也是 AI 友善設計的一環。為了建立信任，介面可以對 AI 生成的文字或決策加上標記，例如顏色徽章或小圖示，區分哪些內容是 AI 建議、哪些是人工確定。

這樣的標識一方面讓使用者明白哪些資訊需要特別覆核（因為是 AI 產出），另一方面在心理上也保持透明度，避免使用者混淆 AI 與人為內容。

總之，AI 友善的 UI 設計應當讓 AI 功能如影隨形地嵌入使用者工作流程，不打斷、不越權，並且讓使用者隨時介入掌控。

💡 Gary’s Pro Tip｜易用且不強制的 AI 功能
設計 AI 功能介面時，讓 AI 建議隨選隨用且易於忽略。例如，可以使用一個輕量的圖示或按鈕提供 AI 建議，讓有需要的用戶點擊；不想用的人則不會被干擾。永遠確保 AI 不會擅自改動內容，所有更動都需經過使用者明確確認。

提示輸入與 AI 回饋區塊設計

AI 功能的介面設計重點在於：如何讓使用者方便地給出提示詞，以及如何直觀地呈現 AI 的回饋。以下我們以 Odoo 18 的 Helpdesk 和 CRM 為例，說明提示輸入區與 AI 回饋區塊的設計。

Helpdesk 工單中的 AI 助手對話

客服人員在查看支援票據時，透過右側的 AI 助手對話介面，直接向 OdooBot 輸入指令。Odoo 根據當前工單內容，自動產生一則回覆建議並顯示在對話區域中供人員參考。

整個提示輸入與回饋過程都緊貼在工單頁面進行，AI 回覆建議下方附有「Send as Message」（發送訊息）等操作按鈕，方便人員一鍵採用建議。

這樣的設計將提示詞輸入框和AI 回饋訊息置於工單對話的脈絡旁邊，使客服人員不必跳出介面就能獲取摘要、擬好的回覆或相關知識庫文章建議。

CRM 銷售情境中的 AI 建議

在銷售單（如報價 S00093）中使用 AI 助手，使用者在右側的 AI 面板輸入對 AI 的請求（例如要求 AI 草擬一封後續跟進的郵件），OdooBot 隨即根據該報價單的內容與上下文，產生一封專業且具有禮貌語氣的郵件草稿建議。

該建議直接顯示於 AI 面板中，包含稱呼客戶的問候語和跟進細節，使用者可以檢視滿意後點擊「Send」將此內容發送給客戶。

將 AI 提示輸入區塊（右下方的對話輸入框）以及AI 回饋內容區塊（OdooBot 回覆的郵件草稿）緊密結合。這種內嵌式的提示-回應區設計，確保 AI 功能融入銷售人員日常使用的界面，提供如同智慧助理般的體驗。

在 Helpdesk 與 CRM 模組中，除了上述對話式的 AI 助理介面，還有其他形式的提示與回饋設計。例如：摘要與意圖分類功能。

Helpdesk 工單往往內容冗長，Odoo 18 的 AI 可在一鍵之下讀取整個對話紀錄並生成重點摘要，這個摘要建議可顯示在工單頁面的一個專門區塊，協助工程師快速瞭解案件重點。

類似地，對於新進的郵件詢問，系統能透過 NLP 技術預判客戶意圖並自動分類，如識別出支援郵件的類型（抱怨、故障、詢價等）。

介面上可以在工單標題或分類欄位旁，呈現一個「AI 建議分類：可能為『故障報告』」的提示，經由人工確認後一鍵套用至正式分類欄位，以減少人工判別的時間。

再比如快速標籤（Quick Tags）與自動欄位填充。AI 若預測出適合的標籤（如產品類別、問題類型），介面上可直接顯示這些推薦標籤按鈕，使用者點擊即可將標籤附加到紀錄中。

同樣地，在 CRM 中，如果使用者新建一筆潛在客戶紀錄、輸入了公司網址，AI 能即時擷取網路資訊自動填入公司名稱和產業等欄位。

UI 設計上，可以將這些 AI 帶出的欄位值以草稿狀態顯示（例如淺色文字或附上「AI 建議」字樣），讓業務員確認後按一下 ✅ 完成填入。這樣的提示區塊設計結合了Prompt Engineering背後的智能推理與直觀的UI呈現，使使用者得到「伸手可得」的建議，同時保有核查的機會。

綜合來說，設計提示輸入與回饋區塊時，要讓AI 輸入與輸出都貼合使用情境：輸入區提供足夠的上下文（有時甚至可以隱性地由系統代填部分 prompt，以減輕使用者負擔），輸出區則以易讀易用的方式呈現結果，讓使用者一目了然該如何應用 AI 回饋。

強調與建議：提升信任感的回饋設計

當 AI 介入內容產生或決策建議時，一個良好的 UI 應該提供適當的回饋方式來讓使用者安心採用。常見的作法包括強調顯示、建議列以及修改追蹤等，這些都屬於增進 AI 透明度與使用者信任的 UX Pattern。

強調顯示

在 AI 生成內容後，系統可以將新增或變動的部分以強調方式標示，讓使用者一眼看出 AI 帶來了哪些更動。

例如，當 AI 幫助業務人員重寫一封郵件時，可以將修改過的句子或替換的用詞用不同底色標出，類似於文字處理軟體中的修訂模式。透過這種視覺強調，使用者能清晰地了解 AI 的作用範圍，而不必猜測模型改了什麼。

再如，在 Helpdesk 工單中，如果 AI 判斷該案件措辭激烈、可能很緊急，系統會提前將該工單以特殊樣式強調顯示，提醒支援人員優先處理。這些強調設計有效提高了資訊的可見度與重要性，使 AI 的洞察轉化為明確的視覺提示。

建議列與提示氣泡

有時候 AI 會提供不只一種建議，例如多種回覆語氣或不同重點的摘要。此時可以運用**建議列（suggestion bar）**在介面中羅列出數個選項，讓使用者自行挑選最適合的。

另一種形式則是對特定文字片段提供即時建議氣泡：當使用者選取一段AI產生的文字時，彈出一個小選單，裡面有「重新生成類似內容」「語氣更禮貌」「縮短此段」等指令可供選擇。

這種設計讓使用者能夠對 AI 輸出進行細粒度的控制，透過操作簡便的UI來微調結果，而不必完全從頭重來。建議列與氣泡不僅提升了互動性，也傳達出「AI 可以被引導」的訊息，讓使用者覺得自己仍掌握在駕駛座上。

修改追蹤（版本比較）

為了讓使用者放心接受 AI 建議，介面還可以提供原始內容與AI建議內容的差異檢視。

例如在CRM的郵件編輯器中，當使用者按下一鍵改寫後，系統可以顯示一個對比視窗或交錯強調的文字，標示出哪些字句是 AI 修改的。

使用者可以逐項瀏覽改動並決定是否接受。這有點像程式碼版本控制中的 diff，或文件編輯中的修訂模式。透過直觀的差異呈現，AI 建議轉化為清晰的「修改清單」，使用者因而更容易信任建議（因為看得懂改了什麼）且可選擇性地採用。

事實上，在 AI 產出與人類確認之間引入一層明確的區分，例如以標籤或色碼標明「AI 生成」內容 vs. 「人已確認」內容，這種透明度設計增強了使用者對系統決策的理解，有助於他們放心地將 AI 融入日常流程。

💡 Gary’s Pro Tip｜慎選 AI 修改文字的顏色
在UI中標示 AI 修改內容時，建議使用柔和的視覺強調。例如以淺黃色底紋來突顯 AI 新增的文字，而非刺眼的紅字刪除線。這樣能提醒使用者注意變動，同時不至於讓介面看起來像錯誤很多般地令人緊張。記住，強調是為了提供信心而非增添壓力。

提升 AI 體驗的 UX 策略

良好的 AI/UX 不僅關乎介面上的元素呈現，還涉及整體體驗流程的優化。以下幾項策略能讓 AI 融入 Odoo 應用時更順暢、貼心：

• 預設值與自動完成：當AI有高信心的建議時，不妨直接以預設值呈現在欄位中，減少使用者手動輸入的工作。例如在 CRM 中，使用者輸入客戶公司網址後，AI 自動填入「產業類別」欄位，這時可以先將該值顯示為預設選項等待確認。又或者 AI 預測某張支援票的優先級為「高」，則預先選取此優先級但允許人員改回。透過這種智能預設，系統替使用者做好了 80%的工作量，同時尊重他們最終的選擇權。預設值策略的重點在於降低門檻：使用者如果認同建議，只需直接接受即可；若不認同，仍可自行修改，沒有任何強制成本。
• 智慧過濾與內容精選：AI 產生的結果有時過於冗長或包含不相關部分，此時介面應協助篩選精華。一種方式是在後端預先對 AI 回覆做過濾，只呈現最相關的片段給使用者；另一種則是提供使用者交互式的過濾工具。例如，當 AI 給出知識庫文章清單時，介面可按相關度排序並標示出與當前問題最匹配的幾篇，其他的收起以免干擾。又或者在客服回覆草稿中，強調那些直接回答問題的句子，將客套寒暄部分淡化處理，以便支援人員快速確認重點。總之，讓重要資訊脫穎而出、次要資訊低調陪襯，是提高 AI 建議實用性的重要UX手段。
• 友善的錯誤與信號：無可避免地，AI 有時會失靈或給出不理想結果。此時 UX 要特別注意錯誤訊息的措辭與反饋速度。假如 AI 服務因網路問題無法取得回應，介面應彈出友善的提示告知，例如：「AI 助理暫時忙線中，請稍後再試」，而非拋出技術錯誤碼。再者，可以給使用者補救建議，如提供重新嘗試按鈕或引導至傳統查詢途徑。這種體貼的錯誤處理文字可減少使用者的挫折感，讓他們明白問題可逆且系統已有應變措施。
• 速度回饋與進度提示：AI 回應的速度對體驗至關重要。如果等待時間超過幾秒，務必在UI上顯示進度回饋。例如在按下「生成回覆」按鈕後，立即切換按鈕狀態為 Loading... 或顯示一個小旋轉圖示，告知使用者系統正在思考中。Odoo 介面也可以仿照聊天室顯示「AI 正在輸入…」的狀態，減少使用者主觀等待時間。當可能需要較長時間計算時，可以逐步呈現結果：例如先顯示大致框架，隨後細節填充。而如果AI能流式（stream）傳輸內容，更可讓文字一字字地顯現，營造出即時輸出的視覺效果。這些速度方面的UX優化，旨在防止使用者因等待無反應而產生不安，並保持他們的操作節奏不被打斷。

OWL 與 QWeb 的 AI 互動實作

在了解了設計理念後，我們最後來看看在 Odoo 18 中如何透過程式碼實作這些 AI 互動介面。

Odoo 18 引入了全新的前端框架 OWL (Odoo Web Library)，讓開發者可以採用元件化的方式建立動態 UI 元素。

OWL 元件使用 JavaScript+XML 的組合，能夠輕鬆地與 Odoo 後端交互並即時更新界面。

傳統的 QWeb 模板則依然可用於靜態部分的呈現。例如，我們可以用 QWeb 在表單視圖上新增一個欄位，用來顯示 AI 自動填入的建議值；而當需要即點即得的交互（例如點擊按鈕呼叫 AI 並更新內容）時，則優先使用 OWL 來實現無刷新動態更新。

下面提供一段簡化的範例程式碼，說明如何以 OWL 建立一個 AI 建議元件。此元件以 Helpdesk 工單為例，按一下按鈕即向伺服器請求 AI 建議回覆，然後將結果即時顯示在介面上供使用者編輯確認：

/** @odoo-module **/
import { Component, useState } from "@web/core/owl";

export class TicketAiSuggest extends Component {
    static template = "helpdesk.TicketAiSuggestTemplate";
    setup() {
        this.state = useState({ suggestion: "", loading: false });
    }
    async generateSuggestion() {
        this.state.loading = true;
        // 呼叫後端控制器以取得 AI 建議文本
        const result = await this.env.services.rpc({
            route: "/helpdesk/ai_suggest",
            params: { ticket_id: this.props.ticketId }
        });
        this.state.suggestion = result.message;  // 假設後端回傳建議內容
        this.state.loading = false;
    }
}

上面的 JavaScript 定義了一個 OWL 元件 TicketAiSuggest，使用 useState 來管理內部狀態，包括目前的建議內容和載入狀態。

點擊按鈕時，generateSuggestion() 方法透過 RPC 呼叫 Odoo 後端路由（例如接合 OpenAI API 的控制器），將當前工單 ID 發送出去並請求 AI 產生回覆。在等待過程中將 loading 狀態設為 true 以禁用按鈕並顯示「產生中」文字。

當 AI 結果返回後，程式將建議文字存入 state.suggestion，隨即 loading 設為 false，UI 即會自動更新顯示一個含該建議文字的 <textarea>。

我們在 <textarea> 上用了淡黃色背景（#fffbcc）作為強調，以提示這段文字是 AI 給出的草稿。使用者此時可以在此文字框中自由編輯調整（Inline Editing），滿意後再將內容貼回正式的回覆欄位送出或直接採用。

<!-- Template: helpdesk.TicketAiSuggestTemplate -->
<t t-name="helpdesk.TicketAiSuggestTemplate">
  <div class="ai_suggest_box">
    <button type="button" class="btn btn-primary" t-on-click="generateSuggestion" t-att-disabled="state.loading">
      <t t-esc="state.loading ? 'AI產生中…' : '生成 AI 建議回覆'" />
    </button>
    <div t-if="state.suggestion">
      <p>AI 建議的回覆：</p>
      <textarea class="ai-result" style="background: #fffbcc;"><t t-esc="state.suggestion"/></textarea>
    </div>
  </div>
</t>

值得注意的是，上述 XML 模板運用了 Odoo 的 t-on-click 綁定事件，以及 t-if、t-esc 等 QWeb 表達式來控制顯示。

這種 OWL + QWeb 的結合，使得元件既能享有前端即時互動，又能輕鬆插入 Odoo 的現有頁面結構。開發人員可以將此元件透過 OWL 的 registry 註冊到特定介面位置，例如工單表單視圖的自訂欄位區域。

一旦註冊完畢，用戶便可以在對應介面看到「生成 AI 建議回覆」的按鈕並使用該功能。

透過 OWL，我們能實現真正即時且直覺的 AI 互動體驗：使用者點擊按鈕，介面隨即反應顯示進度（按鈕文字變化），AI 結果一到即刻呈現且允許編輯，整個過程無須重新載入頁面，體驗流暢自然。

相比之下，如果僅用傳統 QWeb，我們可能需要使用者點擊後刷新頁面或動態插入 HTML，開發複雜度和使用體驗都不及 OWL 元件方案來得優雅。

💡 Gary’s Pro Tip｜善用 OWL 和 QWeb 兩者的優勢
在為 Odoo 開發 AI 功能時，選擇合適的技術很重要。靜態的 AI 輸出（例如表單開啟時自動填入的建議欄位）可以透過服務端計算後直接由 QWeb 顯示。而動態交互（如按鈕即時獲取 AI 建議）則應善用 OWL 元件的優勢來更新UIcybrosys.com。兩種技術搭配使用，能既利用 Odoo 既有框架又確保使用者享有即時互動的極致體驗。

今日結語

總而言之，打造「AI 友善」的 UI/UX 關鍵在於：將 AI 功能巧妙地融入使用者日常操作的介面中，通過良好的設計原則與貼心的體驗優化（預設、快取、回饋迅速），讓 AI 成為默契的數位助手。

Odoo 18 的 CRM 和 Helpdesk 模組已經展現了這樣的設計思維——從一鍵郵件重寫到工單自動摘要，都平順地嵌入在熟悉的界面中。

隨著開發者運用 OWL 等新技術擴展這些功能，未來的人機介面更加直觀聰明，同時仍然維持以使用者為中心的體驗原則，帶來極致的用戶體驗。